home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1069 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.4 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: "Nathan Myers <ncm@cantrip.org>" <ncm@cantrip.org>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Use of standard exception classes
  5. Date: 13 Apr 1996 23:17:30 GMT
  6. Organization: Best Internet Communications
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <316F646D.552DF1DD@cantrip.org>
  9. References: <9604121530.AA08606@sun132.spd.dsccc.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=us-ascii
  13. Content-Transfer-Encoding: 7bit
  14. X-Nntp-Posting-Host: ncm.vip.best.com
  15. X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i386)
  16. Content-Length: 2404
  17. Originator: clamage@taumet
  18.  
  19. Kevin Cline wrote:
  20. > 
  21. > In "The Standard C++ Library" on page 65, Plauger wrote:
  22. > 
  23. >   "I strongly encourage you to follow the lead of the Standard C++
  24. >    library in the use of exceptions:
  25. >    * Throw only objects of one or more classes derived from [exception]
  26. > 
  27. > Page 19-1 of the 4/95 version of the draft says "The Standard C++
  28. > library provides classes to be used to report errors in C++ programs."
  29. > 
  30. > But in section 19.1.1 of the same draft it says:
  31. > 
  32. > "The class exception defines the base class for the  types  of  objects
  33. >  thrown  as  exceptions by *C++ Standard library components*, and certain
  34. >  expressions, to report errors detected during program execution."
  35. > 
  36. > Can someone on the committee indicate whether it was the committee's
  37. > intention for the standard exception class hierarchy to be used in
  38. > general C++ programming, or whether the intention was for the standard
  39. > exception class hierarchy to be reserved to the Standard C++ library?
  40.  
  41.  
  42. In discussion that led to the current formulation for the standard 
  43. exception types, it became clear that they are not general enough
  44. for all uses in user code; the committee agreed that it was sufficient
  45. to standardize just what is needed for the standard library.
  46.  
  47. So use your own exception types, if you like; if you derive from
  48. a standard exception, you probably should use virtual derivation
  49. for reasons John Skaller seems always happy to explain.
  50.  
  51.  
  52. > Another developer on our team has asked
  53. >   How can we be sure that ANSI C++ library callbacks work
  54. >   correctly in the face of exceptions?  What if ANSI C++
  55. >   library code catches *our* exception?
  56. > 
  57. > Is this a problem, or are library functions required to reraise any
  58. > exceptions thrown by client code?
  59.  
  60. I assume that by "library callbacks" s/he means member functions
  61. invoked by library components?
  62.  
  63. Bad things happen if you throw during copy construction or destruction
  64. of a vector element.  Don't let it happen.  (Yes, I know this is easier
  65. said than done.  Still.)   There are lots of things in the library that
  66. could break if a user object (or even a standard object!) throws during
  67. a standard function.  Probably there are some places where it would be
  68. safe, but the committee hasn't identified them except in iostreams, where
  69. it's specified under what circumstances exceptions are caught and rethrown.
  70.  
  71. Nathan Myers
  72. ncm@cantrip.org  http://www.cantrip.org/
  73.  
  74.  
  75. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  76. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  77. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  78. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  79. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  80.